1. Field of the Invention
The present invention relates generally to a multiprocessor code fix using a local cache, and more particularly pertains to a multiprocessor code fix system and method wherein operating code fixes are supplied to the multiple processors which utilize the same operating code by storing the correction code fixes in a central RAM, and distributing the code fixes over a dedicated code fix bus to a local cache for each processor.
2. Discussion of the Prior Art
As ASICs (Application Specific Integrated Circuits) have become larger and more complex, the use of ASICs in microprocessors and other programmable logic has become more common. The code or software that is used to control these programmable devices must be stored in memory during functional operation. The memory used for the storage of the code can be either RAM (Random Access Memory), ROM (Read-Only Memory) or NVRAM (Non-Volatile RAM). Each of these memory structures has its advantages and disadvantages for storage of the operation code. RAM memory allows the user to change the code at any time after manufacturing, however the code still needs to come from somewhere at power-up time since it disappears after each powering off. ROM memory is the smallest and requires the least power to run, however since the code storage is created during manufacturing it is not able to be changed afterward. Thus a bug or problem in the code means that the ASIC must be thrown away. NVRAM memory compromises between RAM and ROM and allows the code to be written into it after manufacturing but retains the code even when no power is applied to the circuit. Unfortunately, the size, speed, and manufacturing cost of nonvolatile RAM is not competitive with ROM and RAM.
FIG. 1 illustrates one practical prior art solution to this code storage problem which uses ROM for the majority of storage, and then place breaks in the code between sections of code that check in a RAM storage area to see if the next section of code is valid. The RAM is loaded at power up from an off chip EEPROM (Electronically Erasable/Programmable ROM). The ROMs inside the ASIC contain jump tables for each section of code. When the ROM reads the first section of code, it is told to jump to a location in the RAM. If the code is OK, the RAM simply sends back a return statement and the code is executed from the ROM.
If, however, there is a bug in the ROM code, as illustrated at addresses/locations 0x100C and 0x1010 which contain bad code, when the ROM reads the first section of code at address 0x1008, and is told by instruction JUMP 0x0FEC to jump to address 0x0FEC in the RAM. The RAM contains the fixed code at the next addresses 0x0FF0, 0xOFF4, 0x0FF8, and thus the processor runs from the new code in the RAM until the end of the section at address 0x0FFC, where the RAM gives the return command to JUMP 0x01024, and execution resumes from address 0x1018 in the ROM. The drawbacks to this method are that it takes time at each powerup for the RAM to load in the fixed code from the EEPROM.
The solution of FIG. 1 optimizes the use of ROM (the smallest and least power usage memory), and uses the smallest amount of RAM requiring loading from power-up. This solution also allows for the possibility that no code changes are needed and no RAM loading required. However, it requires that a small amount of processing time is used for checking the validity, and a small amount of storage space is used for the branching code. One problem is determining the granularity of the breaks and the amount of RAM included in the design. This granularity and RAM storage must be predicted before manufacturing and with no knowledge of the extent of the problems present in the code.
The solution of FIG. 1 works well given the limitations of technology, however as the number of processors on a chip increases, as in chips used in internet processors for example, the amount of RAM for fixes increases and the amount of time or buses required to load the RAM at power-up increases. A typical group of four processors (a square works best since it uses minimal space) requires four times the resources for the bug fixes. If four of these processor groups are then further grouped, the resource demand increases by sixteen.
From a software perspective, there is an additional factor in the use of more processors. Sixteen processors with independent code require sixteen times the software effort. What is effective in many applications is to duplicate the code in all of the processors and to use these processor groups as processing engines for multiple channels of data. For example, a modem can use multiple processors to handle multiple communication channels. This approach limits the amount of software effort required to take advantage of the use of multiple processors.
The problem of code fixes now becomes a case of the same fixes being duplicated over each processor. (The use of a single ROM for the processor becomes intractable as the number and speed of processors increases).